> > > > the kernel level. Still, for mountd the use is limited, you can, of course > > implement a source routed mount request to mountd, using strict routing, > > and it might be relatively easy to obtain a filehandle, however this will > > MIGHT be?! ? > > "Using strict routing" doesn't make much of a difference in this > scenario, except that it limits what hosts you can hit (if it'll work at > all with strict routing... I've never tried it) because of the limited > space in the options field of the IP header. A loose source route will > serve a hacker's purposes just fine, Thank You Very Much. I have failed to do it with loose routing, however it's quite possible that one of intermidiate routers blocked it. However it worked with strict routing. > > And as long as the system in question will accept a source routed packet > and respond (as Net/2 based code should, and the RFC states) with the > inverse of the route, you WILL get a file handle. The whole process of > getting a file handle in NFS relies on address-based authentication. Once > you put yourself in a position where you determine the route that your > target's packets take, addresses cease to be trustworthy. > You repeated my words here. > As for the real-world feasibility of the attack, the tools to do this > exist and are floating around. It isn't particularly hard to do, > either... as long as you know the concept behind it, it's all pretty much > common sense. > So has I said. > > not always give you file access, at times, it gives you read access, > > I suggest you go take a look at the RFC for NFS. Thank you for your suggestion. > > The entire system is BASED on the file handle. The nfs daemon > SPECIFICALLY does not do authentication... I believe (I don't have the > RFC sitting in front of me at this moment) that the system is arranged so > that authentication is seperated from the gritty file i/o stuff, so that > different authentication systems can be arranged. RFC will not give you all information. All I meant was: if more filtering rules on the router are used AND ip source routing is NOT blocked you may find no use out of the filehandle you obtained from your source-routed mount request. There is no doubt that the authentication is based on the filehandle. I didn't claim otherwise. > > If you have the file handle of the exported filesystem you want to > attack, you have every bit of access that the legitimate NFS clients > have. If the legit NFS clients have read only access, yeah, there's no > way I know of to get around that... but otherwise, you're good to go. > > > at times no access at all. If 2049/udp is filtered in the router, > > you can still send an "unlink" requests, and cause damage, however > > you can't retrive data because no reply is sent to you. > > Huh? > > If the port the nfs daemon is talking on is filtered at the router, > unless the attacker can find a way to get around that filter (which > depends on how the router is configured), said hacker is shit out of > luck. Without any way of communicating with the nfsd, "unlink requests" > aren't going to get through. > You're wrong. On configuration when: 2049 udp, which is commonly being used for nfs is blocked, and ip source routing is not, "unlink requests" are GOING to get through -- in fact, any request will go through that doesn't require any reply. Think of the logics > Of course, the nfs daemon communicates through UDP... and UDP is Real > Real Easy to spoof. If your router will allow certain packets (ANY > packets, in fact) through whatever filtering mechanism you have set up, > you've got a potential vulnerability... You may apply filtering mechanisms that would reject packets that pretend tobe coming from your internal network through the network interface that handles all "external" traffic. > > BUT... > > An "unlink request" (as you put it) still requires a valid file handle > (what inode are we addressing here?). If you have an EXTREMELY determined > assailant on your hands, you have a potential problem in that there's a > limited number of possible file handles for a filesystem to have, and if > someone tried hard enough, they'll EVENTUALLY come across the right one. > > I've never done it. It can definitely be done, but I don't even KNOW of > anyone who will actually sit and try to guess file handles. It'd be > pretty trivial to write up a program that would continually send unlink > RPC's with guessed handles, though... nohup it, stick it in the > background on a secured system, and let it run for a few months, and see > how much trouble it causes. > > Of course, if the mountd isn't appropriately secured, guessing file > handles ceases to be a problem. Of course, if the mountd isn't > appropriately secured, why waste time with unlink requests when you can > just bust out with "rm *"? Wrong approach